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Abstract 


The link quality mechanism of the Mobile Ad Hoc Network (MANET) 
Neighborhood Discovery Protocol (NHDP) enables "ignoring" some 1-hop 
neighbors if the measured link quality from that 1-hop neighbor is 
below an acceptable threshold while still retaining the corresponding 
link information as acquired from the HELLO message exchange. This 
allows immediate reinstatement of the 1-hop neighbor if the link 
quality later improves sufficiently. 


NHDP also collects information about symmetric 2-hop neighbors. 
However, it specifies that if a link from a symmetric 1-hop neighbor 
ceases being symmetric, including while "ignored" (as described 
above), then corresponding symmetric 2-hop neighbors are removed. 
This may lead to symmetric 2-hop neighborhood information being 
permanently removed (until further HELLO messages are received) if 
the link quality of a symmetric 1-hop neighbor drops below the 
acceptable threshold, even if only for a moment. 


This specification updates RFC 6130 "Mobile Ad Hoc Network (MANET) 
Neighborhood Discovery Protocol (NHDP)" and RFC 7181 "The Optimized 
Link State Routing Protocol Version 2 (OLSRv2)" to permit, as an 
option, retaining, but ignoring, symmetric 2-hop information when the 
link quality from the corresponding 1-hop neighbor drops below the 
acceptable threshold. This allows immediate reinstatement of the 
symmetric 2-hop neighbor if the link quality later improves 
sufficiently, thus making the symmetric 2-hop neighborhood more 
"robust". 
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Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7466. 


Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Iz 


Introduction 


Section 14 of the MANET Neighborhood Discovery Protocol (NHDP) 
[RFC6130] contains a link admission mechanism known as "link quality" 
that allows a router using that protocol to "take considerations 
other than message exchange into account for determining when a link 
is and is not a candidate for being considered as HEARD or 
SYMMETRIC." Specifically, [RFC6130] permits a router to disallow 
consideration of some of its 1-hop neighbors for as long as the 
quality of the link from that 1-hop neighbor is below an acceptable 
link quality threshold. 


A feature of this mechanism is that while the link quality remains 

too low, the link information, established by the exchange of HELLO 
messages, is retained. Thus, if the link quality later goes above 

the required threshold (note that a hysteresis mechanism means that 
two thresholds are used), then the link is immediately established 

and will be immediately available for use. 


[RFC6130] collects not only 1-hop neighbor information, but also 
information about symmetric 2-hop neighbors. However, [RFC6130] 
specifies that if a 1-hop neighbor was, but no longer is, considered 
symmetric, then the corresponding 2-Hop Tuples that may have been 
recorded for that 2-hop neighbor are to be removed without a 
retention mechanism for a (possibly temporary) loss due to link 
quality. 


This means that if there is a short period in which link quality is 
too low, then when the link quality is re-established all 1-hop 
neighbor information is immediately available for use again. 
However, the corresponding symmetric 2-hop neighbor information has 
been removed and is not available for use until restored by receipt 
of the next corresponding HELLO message. 


This specification describes how [RFC6130] can be modified to avoid 
this situation by retaining (but not using) 2-hop information, 
similar to what is done with 1-hop information. This modification is 
strictly optional, and routers that do and do not implement it can 
interwork entirely successfully (as they also can with different link 
quality specifications). In addition, by a suitable interpretation 
(that ignored 2-Hop Tuples are not externally advertised), this 
change can be invisible to any other protocols using [RFC6130], in 
particular [RFC7181]. However, the impact on [RFC7181] when 2-Hop 
Tuples are not so handled is also described (owing to the existence 
of implementations of that protocol that are not modularly separated 
from [RFC6130]). 


This specification therefore updates [RFC6130] and [RFC7181]. 
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This update to [RFC6130] does not change the definition of a 
symmetric 2-hop neighbor but adds new state information to each 2-Hop 
Tuple of [RFC6130]. This is to retain some 2-hop neighbor 
information while recording it as currently not to be used. The new 
state information and retained 2-Hop Tuples are reflected in the 
corresponding tables of the updated NHDP-MIB module [NHDP-MIB]. 


2. Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
[RFC2119]. 


Additionally, this document uses the terminology of [RFC6130] and 
[RFC7181]. 


3. Applicability Statement 


This specification updates [RFC6130]. The optimization presented in 
this specification is simply permissive, as it allows retaining 
information that otherwise would have been removed but does not use 
that information except when it could have been used by [RFC6130]. 


This can, in some cases, ensure that the symmetric 2-hop neighborhood 
is more robust against temporary link quality changes and 
consequently yields a more stable network. The only other 
consequence of this optimization is that state for some otherwise 
expired 2-Hop Tuples may be maintained for longer. 


This specification also updates [RFC7181]. This could have been 
avoided had instead [RFC6130] been updated so as to make the changes 
to it invisible to any other protocol using it. However, as it is 
known that some implementations of [RFC7181] are not independent of 
the implementation of [RFC6130] that they use, it is useful to 
indicate the direct impact on [RFC7181]. 


A router that implements the optimization described in this 
specification will interoperate successfully with routers that 
implement [RFC6130] but do not implement this optimization. 


4. Changes to NHDP 


The following changes are made to [RFC6130] if using this 
specification. Note that while this specification is OPTIONAL, if 
any of these changes are made, then all of these changes MUST be 
made. 
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4.1. Interface Information Bases 


The 2-Hop Set is modified by adding this additional element to each 
2-Hop Tuple: 


N2_lost is a boolean flag, which indicates the state of the 
corresponding Link Tuple. If L_status = SYMMETRIC (and thus 
L_lost = false), then N2_lost = false. If L_SYM_time has not 
expired, and L_lost = true (and hence L_status = LOST), then 
N2_lost = true. 


In all other cases, including other cases with L_status = LOST, there 
will be no such 2-Hop Tuples. 


4.2. HELLO Message Processing 
In Section 12.6 of [RFC6130], make the following changes: 


o In point 2, change "L_status = SYMMETRIC" to "L_SYM time not 
expired". 


o In point 2, point 1, point 1, under "then create a 2-Hop Tuple 
with:", add a second bullet point "N2_lost: = L_lost". (Note that 
"2-Hop Neighbor Tuple" has been corrected here to "2-Hop Tuple" 
per [Err4276].) 


4.3. Information Base Changes 

In Section 13, replace the second bullet point with: 

o A Link Tuple’s L_status changes from SYMMETRIC, L_SYM_time 
expires, or the Link Tuple is removed. In this case, the actions 
specified in Section 13.2 are performed. 

Replace the paragraph after the bullet points with: 

If a Link Tuple is removed, or if L_HEARD_time expires and either 

L_status changes from SYMMETRIC or L_SYM_time expires, then the 


actions specified in Section 13.2 MUST be performed before the 
actions specified in Section 13.3 are performed for that Link Tuple. 
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In Section 13.2 of [RFC6130], add the following before all other 
text: 

For each Link Tuple that has L_SYM_time not expired: 
1. If L_SYM_time then expires, or if the Link Tuple is removed: 
1. Remove each 2-Hop Tuple for the same MANET interface with: 


+ N2_neighbor_iface_addr_list contains one or more network 
addresses in L_neighbor_iface_addr_list. 


2. If L_status then changes from SYMMETRIC to LOST because L_lost is 
set to true: 


1. For each 2-Hop Tuple for the same MANET interface with: 


+ N2_neighbor_iface_addr_list contains one or more network 
addresses in L_neighbor_iface_addr_list; 


set N2_lost := true. 


Also, in Section 13.2 of [RFC6130], remove point 1 and renumber point 
2 as point 1. 


4.4. Constraints 


In Appendix B of [RFC6130], under "In each 2-Hop Tuple:", change the 
first bullet point to: 


o There MUST be a Link Tuple associated with the same MANET 
interface with: 


* Lneighbor_iface_addr_list = N2_neighbor_iface_addr_list; AND 


* L_ SYM time not expired; AND 
* L_lost = N2_lost. 
5. Changes to OLSRv2 
If the implementation of [RFC6130] conceals from any protocol using 
it the existence of all 2-Hop Tuples with N2_lost = true, then no 


changes are required to any protocol using [RFC6130]; in particular, 
no changes are required to [RFC7181]. 
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However, if instead the implementation of [RFC6130] makes all 2-Hop 
Tuples visible, including those with N2_lost = true, then protocols 
using [RFC6130] MUST ignore such 2-Hop Tuples. 


For [RFC7181], given that this protocol uses 2-hop information for 
Multipoint Relay (MPR) Set and Routing Set calculation but does not 
include that information in control traffic, this means that an 
implementation must be behaving (i) as if a 2-Hop Tuple only exists 
if N2_lost=false and (ii) as if a change of N2_lost (from false to 
true, or true to false) corresponds to a 2-Hop Tuple appearing or 
being removed. Specifically, this means behaving as if all of the 
following changes were to be made to [RFC7181]: 


o In Section 17.6 of [RFC7181], point 1, replace the final two 
bullet points with: 


* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC and N2_lost 
= false is added or removed; OR 


* A 2-Hop Tuple with N2_out_metric != UNKNOWN_METRIC has N2_lost 
changed; OR 


* The N2_out_metric of any 2-Hop Tuple with N2_lost = false 
changes, and either the flooding MPR selection process uses 
metric values (see Section 18.4), or the change is to or from 
UNKNOWN_METRIC. 


o In Section 17.6 of [RFC7181], point 3, replace the final two 
bullet points with: 


* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC and N2_lost = 
false is added or removed; OR 


* A 2-Hop Tuple with N2_in_metric != UNKNOWN_METRIC has N2_lost 
changed; OR 


* The N2_in_metric of any 2-Hop Tuple with N2_lost = false 
changes. 


o In Section 17.7 of [RFC7181], in the fifth bullet point, add "and 
N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". 


o In Section 18.4 of [RFC7181], in the third bullet point, add", 
N2_lost = false" after "N2_out_metric != UNKNOWN_METRIC". 


o In Section 18.5 of [RFC7181], in the third bullet point, add", 
N2_lost = false" after "N2_ in metric != UNKNOWN_METRIC". 
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6. 


7. 


7. 


7 


o In Section 19.1 of [RFC7181], in the final main bullet point 
(marked as "(OPTIONAL)"), add "and N2_lost = false" after 
"N2_out_metric != UNKNOWN_METRIC". 


o In Appendix C.7 of [RFC7181], in point 1, add "and N2_lost = 
false" after "N2_out_metric != UNKNOWN_METRIC". 


Security Considerations 


The update to [RFC6130] enables the retention and reuse of some 
information collected by that protocol, for only the duration that it 
could have been used in any case. As such, this protocol introduces 
no new security considerations to an implementation of [RFC6130] or 
of any other protocol that uses it, such as [RFC7181]. 
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